6-keem
Gallery
About
© Powered by 6-keem

오픈소스 개발자 대회 협업 규칙

오픈소스 개발자대회
2025년 07월 02일
7분
On this page
  • 1. 브랜치 전략 (Branch Strategy)
  • 1.1 주요 브랜치
  • 1.2 보조 브랜치
  • 1.3 브랜치 생성 및 병합 흐름
  • 2. 커밋 규칙 (Commit Convention)
  • 2.1 Commit message 구조
  • 2.2 Commit message 규칙
  • 3. Pull Request 규칙
  • 3.1 리뷰어 지정 (Reviewer Assignment)
  • 3.2 PR 양식 및 머지 방식
이전 글이 없습니다
다음 글이 없습니다
thumbnail.png

1. 브랜치 전략 (Branch Strategy)

1.1 주요 브랜치

  • master: 프로덕션(배포)용으로 사용되는 최종 안정 브랜치. 스프린트 종료 시 release에서 병합되며 버전 태그(v0.0.1) 부여
  • release: 프론트 팀 내 QA 및 릴리즈 준비를 위한 브랜치
  • develop: 기능 개발 완료 후 테스트 및 통합을 위한 브랜치

1.2 보조 브랜치

  • feature/: 퍼블리싱 화면을 실제 프론트 개발로 전환하는 브랜치
    예) feature/티켓번호, feature/티켓번호
  • publish/: 퍼블리싱 작업을 위한 화면 설계 또는 초기 UI 구성 브랜치
  • hotfix/: 프로덕션에서 발견된 긴급 버그 수정에 사용
    예) hotfix/issue-32, hotfix/issue-24

1.3 브랜치 생성 및 병합 흐름

브랜치 전략브랜치 전략

  1. 작업 전 develop 브랜치에서 새로운 feature/, publish/ 브랜치를 생성
  2. 작업 완료 후 PR 작성 및 리뷰어 지정 (nahyeongjin1 → 6-keem → hyynjju → nahyeongjin1 순)
  3. 리뷰 완료 후 develop 브랜치로 머지
  4. 긴급 수정 사항은 누구나 hotfix/ 브랜치를 만들어 수정 후 develop과 master로 병합
  5. 프론트 테스트 완료 시 develop에서 release로 병합
  6. 스프린트 종료 시 release를 master로 병합하고, 버전을 v0.0.1 단위로 태깅 (개발 기간 한정)

2. 커밋 규칙 (Commit Convention)

2.1 Commit message 구조

헤더는 필수이며 범위, 본문, 바닥글은 선택사항
<type>(<scope>): <subject> - 헤더
# 개행
<body> - 본문
# 개행
<footer> - 바닥글

<type>은 커밋 유형을 나타내며 아래 중 하나여야 한다.

feat: 새로운 기능 추가
fix: 기능 수정
bugfix: 버그 수정
comment: 주석 추가
docs: 문서 수정(README.md 등)
style: 스타일 수정(디자인 수정, 코드 포맷팅, 세미콜론 누락 등)
refactor: 코드 리팩토링(기능 수정 없이 구조만 개선)
test: 테스트 코드 추가 또는 수정
chore: 빌드 업무, 패키지 매니저 수정 등
perf: 성능 개선

2.2 Commit message 규칙

제목 Header

  1. 제목과 본문을 빈 행으로 구분한다.
  2. 제목은 50글자 이내로 제한
  3. 제목의 첫 글자는 대문자로 작성
  4. 제목 끝에 마침표 넣지 않기
  5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
feat: Add user login feature

본문 Body

  1. 선택 사항
  2. 본문의 각 행은 72글자 내로 제한
  3. 본문은 어떻게보다 무엇을, 왜에 맞춰 작성하기
- Created new LoginScreen for user authentication
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials

바닥글 footer

  1. 선택사항
  2. 이슈를 추적하기 위한 ID를 추가할 때 사용
    해결 - 해결한 이슈 ID
    관련 - 해당 커밋에 관련된 이슈 ID
    참고 - 참고할만한 이슈 ID
해결: #123
관련: #321
참고: #222

커밋 예시

feat: Add user login feature <- 요약된 설명
 
- Created new LoginScreen for user authentication <- 비교적 자세한 설명
- Implemented Firebase Auth for credential management
- Added error handling for invalid credentials
 
해결: #123 <- 해결된 이슈

3. Pull Request 규칙

3.1 리뷰어 지정 (Reviewer Assignment)

nahyeongjin1 → 6-keem → hyynjju → nahyeongjin1

  1. 정해진 순서에 따라 리뷰어 지정
  2. feature/, publish/ 브랜치는 리뷰 완료 후 develop으로 머지
  3. hotfix/는 긴급 상황에 따라 누구나 생성 및 병합 가능
  4. 리뷰어가 제안하는 수정 사항이 있는 경우 PR 제목을 [WIP]: ** 형식으로 수정하고, 리뷰어는 머지 금지. 작성자는 수정 후 request review 요청
  5. PR을 열기 전에 항상 develop 브랜치 기준으로 rebase 후 force push (레인보우 방지)

3.2 PR 양식 및 머지 방식

  • PR 제목 형식: [JIRA TICKET] 티켓 제목
  • PR 머지 시 반드시 Squash Merge 사용
  • 머지 메시지 형식: [JIRA TICKET] 티켓 제목 (#PR번호)

예시 템플릿

<h3>JIRA Task 🔖</h3>
 
- **Ticket**: [티켓번호](링크)
- **Branch** : feature/티켓번호
 
<h3>작업 내용 📌</h3>
 
- 이번 PR에서 **무엇**을 구현/수정했는지 요약
- 주요 변경 사항을 간단히 기술
 
<h3>변경 사항 🖥️</h3>
 
- UI 변경이 있는 경우, 스크린샷 첨부
 
<h3>테스트 방법 🧑🏻‍🔬</h3>
 
- 리뷰어가 확인해야 할 테스트 시나리오, 시뮬레이션 방법
- 예상되는 결과(기대값)와 실제 결과 비교
- 테스트 환경(에뮬레이터, 실제 디바이스, OS 버전 등)
 
<h3>참고 사항 📂</h3>
 
- 관련 이슈 번호: `Closes #123`
- 참고 문서, 레퍼런스 링크
- 기타 특이 사항, 향후 개선 사항